home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / njm / njm-minutes-90feb.txt < prev    next >
Text File  |  1993-02-17  |  4KB  |  150 lines
  1.  
  2.  
  3.         IETF JOMAAN WORKING GROUP
  4.  
  5.     minutes of 2/6/89 Philip Almquist, secretary
  6.  
  7. I: Announcement of User to User Connectivity Problems Working Group
  8.  
  9.     - new IETF group, chaired by Dan Long of BBN
  10.  
  11.     - will produce a paper on how end users can/should seek to resolve
  12.         Internet connectivity problems
  13.  
  14.     - relationship to JOMAAN to be determined
  15.  
  16.     - unfortunately, neither group can fix broken hosts or broken
  17.         administrators
  18.  
  19. II: Mailing addresses
  20.  
  21.     - mailing list:  njm@merit.edu (njm-request@merit.edu)
  22.  
  23.     - chairperson:  hastings@psc.edu
  24.  
  25. III: Charter
  26.     
  27.     - Gene will mail it out again
  28.  
  29. IV: SNMP community names
  30.  
  31.     - all routers should support "monitor"
  32.  
  33.     - routers under the sole control of the regional NOC should support the
  34.         NSFNET backbone community name
  35.  
  36.     - if neither of the above work to contact some gateway, try "public"
  37.  
  38.     - NSI "agrees in principle" to support community names that they will
  39.         make available to regional NOC's
  40.  
  41.     - ditto for ESNET
  42.  
  43.     - regular polling of routers belonging to other organizations is a
  44.     no-no, except that routers connecting two routing domains may be
  45.     monitored by both NOC's (and should probably send traps to both NOC's).
  46.  
  47.     - the above restrictions on "regular polling" do not preclude sending
  48.         queries to any router while actively debugging a problem
  49.  
  50. V: Network maps
  51.  
  52.  
  53.  
  54.                                    1
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.     - Merit is 90regional maps which are accessible via anonymous FTP
  62.  
  63.     - regionals which have maps available via anonymous FTP should send
  64.     pointers to them to the njm list; Merit will treat this as an implicit
  65.     request to regularly retrieve copies of the map
  66.  
  67.     - all maps should include a creation date
  68.  
  69. VI: NSFNET <--> BBN core interactions
  70.  
  71.     - MERIT and DCA have been working on coordinating responses to
  72.     mailbridge problems at the FIX locations
  73.  
  74. VII: BITNET II
  75.  
  76.     - Scott Brim expressed concern that BITNET II is being designed by
  77.     people who do not understand the Internet topology.  Thus, the
  78.     substantial new load it will place on the Internet may occur in
  79.     inappropriate places.  Scott will investigate further.
  80.  
  81. VIII: Traceroute
  82.  
  83.     - several reported that third party traceroute is a real win, and hoped
  84.     that other routers would support it soon
  85.  
  86. IX: Appropriate us of the "status-reports" mailing list
  87.  
  88.     - the list is appropriate only for reports of current or very recent
  89.     events, such as
  90.  
  91.         * "X will be down from ___ until ___"
  92.  
  93.         * "X is down"
  94.     
  95.         * "X was be down from ___ until ___"
  96.  
  97.     - Summary data can be interesting, but should be posted elsewhere
  98.  
  99. X: FARNET Report (by Guy Almes)
  100.  
  101.     - FARNET wants increased FARNET<->IETF cooperation.  Regionals should
  102.     send people to IETF meetings; these people should report back to the
  103.     regional operators and planners
  104.  
  105.     - periodic reports of usage/uptimes/etc.  are useful (eg, the NSFNET and
  106.     CERFNET monthly reports).  People interested in helping to devise common
  107.     reporting measures should send mail to Guy.
  108.  
  109.     - is application throughput commensurate with theoretical path
  110.     bandwidths (ie, is performance as good as it ought to be)?  This is an
  111.  
  112.                                    2
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.     important question for assessing whether we run networks well and for
  120.     justifying expensive, high-speed paths.  Can we develop a "Dow Jones"
  121.     average of network performance?  Would this measure anything useful, or
  122.     are most problems just broken TCP's that we have no control over?
  123.     Interested parties should contact Guy about starting a joint
  124.     IETF<->FARNET project in this area.
  125.  
  126. XI: NSFNET information files
  127.  
  128.     - there was a request to the NSF NIC to provide a file of responsible
  129.         persons indexed by network number
  130.  
  131.     - other ideas for similar useful files should be sent to nsfnet-info
  132.  
  133. XII: NREN planning
  134.  
  135.     - Steve Goldstein of NSF wants input on how NIC's and NOC's should be
  136.         organized in the NREN
  137.  
  138.     - Gene will send his ideas to the njm list; others may respond
  139.  
  140. XIII: Whois service
  141.  
  142.     - NREN will use an X.500-based whois equivalent
  143.  
  144.     - some suggested that (in the shorter term) the existing NIC whois
  145.     should be replicated on additional machines (this may not be practical)
  146.  
  147.  
  148.  
  149.                                    3
  150.